Théorème CAP
Pour les articles homonymes, voir CAP.
Le théorème CAP ou CDP, aussi connu sous le nom de théorème de Brewer, dit qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps (c'est-à-dire de manière synchrone) les trois contraintes suivantes[1],[2] :
- Cohérence (Consistency en anglais) : tous les nœuds du système voient exactement les mêmes données au même moment ;
- Disponibilité (Availability en anglais) : garantie que toutes les requêtes reçoivent une réponse ;
- Tolérance au partitionnement[Note 1] (Partition Tolerance en anglais) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).
D'après ce théorème, un système de calcul/stockage distribué ne peut garantir à un instant t que deux de ces contraintes mais pas les trois[3].
La meilleure solution connue pour l'arbitrage AP (disponibilité et partitionnement) est d'utiliser un modèle de cohérence relaxé tel que cohérence éventuelle forte (Strong Eventual Consistency, SEC), dont les types de données répliqués sans conflit sont une implémentation.
Historique[modifier | modifier le code]
Le théorème part d'une conjecture énoncée par le chercheur en informatique Eric Brewer de l'université de Californie à Berkeley lors du Symposium on Principles of Distributed Computing (PODC, « Symposium sur les principes d'informatique distribuée »)[4],[1]. En 2002, Seth Gilbert et Nancy Lynch du MIT publient une preuve formelle de la vérifiabilité de la conjecture de Brewer, et en font un théorème établi[1].
Illustrations[modifier | modifier le code]
- Soit A et B deux utilisateurs du système, soit N1 et N2 deux nœuds du système. Si A modifie une valeur sur N1, alors pour que B voit cette valeur sur N2 il faut attendre que N1 et N2 soient synchronisés. Si N1 et N2 doivent toujours servir des valeurs cohérentes, alors il y a un temps incompressible entre le début de l'écriture, la synchronisation et la lecture suivante. Sur un système très chargé et très vaste, ce temps incompressible va considérablement influencer la disponibilité et la résistance au morcellement. Il existe bien évidemment des techniques pour optimiser ce temps mais plus le système est vaste, plus il est difficile à réduire.
- Exemple d'arbitrage qu'implique le théorème CAP : deux utilisateurs qui font une même recherche sur un même moteur de recherche peuvent obtenir des résultats différents, mais on peut considérer que cet inconvénient est moins grave que de ne pas avoir de résultats du tout [5].
Notes et références[modifier | modifier le code]
Notes[modifier | modifier le code]
- Dans cette définition, le terme « partitionnement » ne doit pas être compris au sens que, dans une base, un objet peut être scindé en plusieurs destinations de stockage, mais comme des machines distinctes (appelées généralement nœuds) possédant chacune une partie des données tel que, seul, l’ensemble des nœuds permet de reconstituer l’intégralité des données de la base.
Références[modifier | modifier le code]
- (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « CAP theorem » (voir la liste des auteurs).
- (en) [PDF] Lynch, Nancy, et Seth Gilbert : « Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. » in ACM SIGACT News, v. 33 N°2, 2002, p. 51-59.
- (en) julianbrowne.com : Brewer's CAP Theorem. Consulté le 2 mars 2010.
- (en) royans.net : Brewers CAP theorem on distributed systems.
- (en) Eric Brewer, « Towards Robust Distributed Systems », sur Université Berkeley.
- « davidmasclet.gisgraphy.com/pos… »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?).
Liens externes[modifier | modifier le code]
- (en) Problems with CAP, and Yahoo's little known NoSQL system par Daniel Abadi.
- (en) CAP theorem, almost 2 decades later par Eric Brewer.
